The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter discussed in the background section merely represents different approaches to database management issues, which may be unique on their own.
In conventional database systems, users access data resources from a single logical database. Typically, data is retrieved from and stored to the database using the computing systems or devices of the user. For example, a user system might remotely access one of a plurality of servers that might in turn access the database. The user may issue a query to the database in order to retrieve data. The database processes the query and returns to the user information from the database that is relevant to the query. The maintenance of the database in order to retrieve and deliver accurate information to the user in a timely and efficient manner has been and continues to be a goal of administrators of database systems.
In a multi-tenant database system (“MTS”), various elements of hardware and software of the database may be shared by one or more customers through “cloud computing” solutions which allow service providers to offer access to hardware/software systems through a network, such as the Internet. For example, an application server may be configured to simultaneously process multiple requests for many different customers, and a database may be configured to store data that is shared by many different customers.
Of course, customers of database systems demand that the data they purchase be comprehensive and accurate. An ongoing business enterprise typically maintains significant amounts of data in a database related to the company's business, including information pertinent to sales, revenue, costs, business opportunities, inventory, networking, etc. As one example, electronic business cards or contacts are the lifeblood of many organizations, and the contact information can be maintained in the database. However, keeping contacts or any other information current in a database can be tedious, particularly when the information changes from time to time. For example, the database may have multiple business cards for the same individual, or errors in a business card for the individual.
A typical contact database allows users to enter changes directly to records, such as creating new records, updating existing records, and deleting old records. Of course, allowing direct access by users for changes can sometimes lead to mistakes in the record. In addition, changes may be made by many different sources, and this can lead to conflicting data. Further, it is difficult for the database to easily ascertain the “truth” with regard to a particular database record, such as a business card, or any of its fields or properties. In fact, the best verification that a contact is accurate is the lack of complaint or feedback that the contact was wrong in some respect after a customer purchases the contact.
It would thus be desirable to provide improved systems and methods that permit the database to be updated only when the source of the update has sufficiently trustworthiness.